How to Name and Organize Prompt Files in Your GitHub Repository

tech
github-copilot
prompt-engineering
A comprehensive guide to organizing prompt files, instructions, and agent definitions in your GitHub repository for optimal AI assistant integration
Author

Dario Airoldi

Published

December 26, 2025

How to Name and Organize Prompt Files in Your GitHub Repository

A well-organized repository helps both developers and AI assistants like GitHub Copilot quickly locate the resources they need. Prompt files and their supporting documents benefit from predictable structures and conventions. This article synthesizes the latest GitHub Copilot, Visual Studio Code (VS Code) and Visual Studio documentation, along with community best practices, to provide clear guidance on naming and organizing Copilot-related files.

Table of Contents

📁 Use the .github folder for team-shared prompts and instructions

GitHub Copilot looks in specific subfolders of .github/ to find prompt files, instructions and (in VS Code) custom agent definitions.

Path Purpose
.github/prompts/ Workspace prompt files. Each *.prompt.md file here becomes a slash-command (/promptName in VS Code) or a hashtag command (#promptName or #prompt:<prompt-name> in Visual Studio) when using Copilot Chat. This folder is recognized by VS Code and Visual Studio 2022 (version 17.10+). Older versions of Visual Studio (before 17.10) do not support prompt files. Note that prompt files must use the .prompt.md extension; there is no official support for a plain .prompt extension. The .prompt extension (without .md) is not recognized by Copilot in VS Code or Visual Studio. Each file can start with YAML front matter specifying metadata (name, description, agent, model, tools, etc.) followed by the Markdown content of the prompt.
.github/copilot-instructions.md Repository-level custom instructions. This file provides guidance on how Copilot should behave for your project (coding standards, tool preferences, naming conventions, etc.). It’s automatically applied to all chat requests when the “custom instructions” feature is enabled, and is supported by both VS Code and Visual Studio 17.10+.
.github/instructions/ Path- or language-specific instructions. Store one or more .instructions.md files here. Each file uses YAML front matter fields like applyTo to specify globs (e.g., **/*.cs, docs/**/*.md) that determine when the instructions should be applied. Supported in both VS Code and Visual Studio 17.10+.
.github/agents/ Custom agents for VS Code / Copilot CLI. In VS Code 1.106+ and Copilot CLI, .agent.md files here define specialized personas (e.g., “planning agent,” “test specialist”). Each file contains YAML frontmatter to declare allowed tools, a description, optional handoffs for workflow transitions, model selection, and a Markdown body describing the agent’s behavior. Legacy .chatmode.md files are still recognized but can be migrated using VS Code’s Quick Fix action. Note: This is different from AGENTS.md files (see below).

v1.107+ Features: Claude Skills support for extended agent capabilities. Agents can execute in three contexts: local (interactive), background (work tree isolated), or cloud (GitHub PRs). See How GitHub Copilot Uses Markdown and Prompt Folders for details.
AGENTS.md (anywhere in repo) Agent instructions for Copilot Coding Agent. You can create one or more AGENTS.md files stored anywhere in the repository. The nearest file in the directory tree takes precedence. Alternatively, you can use CLAUDE.md or GEMINI.md in the repository root. These files provide instructions for AI agents working on your codebase, supported in VS Code, Visual Studio, and GitHub.com. Note: AGENTS.md provides instructions to agents, while .agent.md files define custom agent personas.
.github/copilot/ Community convention for shared context. Some teams create a .github/copilot/ folder to gather prompts and domain knowledge (e.g. knowledge/, examples/) in one place. Only a subfolder named prompts/ under .github is recognized by default; other subfolders under .github/copilot serve as shared documentation and must be referenced manually in prompts or instructions.

Note about .prompt.yml files: GitHub also supports .prompt.yml or .prompt.yaml files for storing prompts intended for other GitHub AI tools (such as GitHub Models).
These YAML-based prompt files are not used by GitHub Copilot Chat in VS Code or Visual Studio.
For Copilot Chat, you must use the .prompt.md Markdown format.

Naming Guidelines for Prompt Files

  1. Consistent naming: Use lowercase with hyphens or dots (e.g., create-react-form.prompt.md) to reflect the task or role. The filename or the YAML name becomes the slash/hashtag command.
  2. Single purpose: Each prompt file should perform a distinct, cohesive task (e.g., “generate unit tests” or “review API security”). Avoid mixing unrelated tasks in one prompt.
  3. Descriptive metadata: Include a description in the YAML header. VS Code and Visual Studio display this text when listing the prompt in the Chat UI. You can also set fields like agent (ask, edit, agent mode), model, tools, or argument-hint to refine prompt execution.

💼 Organizing Local Context in .copilot (Optional)

If you want Copilot to provide more project-aware suggestions, consider creating a .copilot/ directory at your repository root. While this is not an official requirement, it’s a community-recommended way to store detailed project documentation, domain concepts, architecture diagrams and other reference materials. Copilot’s semantic search will index the contents of .copilot/context/, making it more likely to find relevant documents when answering questions about your codebase.

A typical .copilot/context/ folder might include:

  • dataschemas/ – JSON or database schema docs.
  • apis/ – internal and external API contracts.
  • patterns/ – coding conventions (e.g., error handling, logging, testing guidelines).
  • workflows/ – business processes and flows.
  • guidelines/ – coding standards, architecture principles, security patterns.
  • images/ and examples/ – diagrams, charts and reference code.

These files do not create slash commands; instead, they enrich the context Copilot can draw upon.

👤 User Prompts in VS Code (Personal Prompt Library)

In addition to workspace prompts, VS Code supports user-scope prompt files that are available across all your projects. These personal prompts are stored in your VS Code profile directory:

  • Windows: %APPDATA%\Code\User\prompts\ (stable) or %APPDATA%\Code - Insiders\User\prompts\ (Insiders)
  • macOS: ~/Library/Application Support/Code/User/prompts/
  • Linux: ~/.config/Code/User/prompts/

User prompt files:

  • Appear in Copilot Chat as slash commands (e.g., /my-personal-prompt) across all workspaces
  • Do not sync to your team via Git (they’re stored locally in your profile)
  • Can be shared across your own machines using VS Code’s Settings Sync feature
  • Follow the same .prompt.md format and YAML frontmatter as workspace prompts

Visual Studio does not currently support user-scope prompt files; it only recognizes workspace-level prompts in .github/prompts/.

💡 Additional Tips

  • Centralize general rules in .github/copilot-instructions.md, and use more granular .instructions.md files for narrower scopes (e.g. language-specific or directory-specific rules). Note that custom instructions must be enabled to be applied in Visual Studio or VS Code.
  • JetBrains IDE support: Prompt files are now supported in JetBrains IDEs (IntelliJ, PyCharm, etc.). You can create prompt files via the settings page under Tools > GitHub Copilot > Customizations, or manually in .github/prompts/. Use /promptName in chat to invoke them.
  • Link to project docs within your prompts or instructions using Markdown links, or use #fetch and #file references in VS Code to import remote or local content into Chat. (These tool references currently work in VS Code Chat; Visual Studio may not support every tool yet.)
  • Iterative improvement: Test prompts and update them based on feedback. Copilot’s responses are non-deterministic; small tweaks often change the quality of output. Encourage team members to contribute and refine prompts.

By following these naming and organization practices—and understanding where each file type is supported—you can ensure that GitHub Copilot operates consistently across your team’s tools and versions.


📦 Supporting Assets: Snippets and Templates

Beyond the core prompt, instruction, and agent files, GitHub Copilot ecosystems often include prompt snippets and templates to streamline development workflows. Understanding when to use each asset type—and where to store them—helps teams build reusable, discoverable resources.

Prompt Snippets

Prompt snippets are reusable text fragments designed to be inserted into chat conversations or combined with other prompts. Unlike full .prompt.md files, snippets are not standalone commands; they serve as building blocks for larger prompts or documentation.

When to Use Prompt Snippets

Use Case Example
Repeated context blocks Standard project architecture descriptions, technology stack summaries
Common instructions Code style reminders, testing requirements, security checklist items
Boilerplate questions “Explain the error handling approach”, “Document the API contract”
Domain vocabulary Business-specific terminology, acronym definitions, concept explanations

Where to Store Snippets

Recommended location: .github/prompt-snippets/ or .copilot/snippets/

.github/
├── prompt-snippets/
│   ├── architecture-context.md
│   ├── security-checklist.md
│   ├── testing-standards.md
│   └── domain-glossary.md

Snippet file characteristics:

  • No YAML frontmatter - Snippets are raw content, not executable commands
  • Not indexed as slash commands - Must be manually referenced
  • Composable - Multiple snippets can be combined in one conversation
  • Lightweight - Short, focused fragments (typically < 50 lines)

How to Reference Snippet Files

GitHub Copilot does not have automatic “include” syntax. To use snippet files, reference them explicitly:

Method 1: File Reference in Chat (VS Code)

Please review this code for security issues.

#file:.github/prompt-snippets/security-checklist.md

Best for: Interactive chat conversations, ad-hoc queries
Guarantees: Content is definitely included in context

Method 2: Markdown Link (Unreliable)

Please review this code following our [security checklist](.github/prompt-snippets/security-checklist.md).

⚠️ Note: Copilot may or may not automatically read linked files
Not recommended for critical content that must be included

Method 3: Copy-Paste When Executing

Please review this code for security issues.

## Security Checklist
[Manually paste security-checklist.md content here when running prompt]

Best for: Ensuring snippet content is definitely included
Use when: #file reference isn’t working reliably

Snippets vs. Embedded Content

When to use snippet files (reusable across prompts):

  • ✅ Content is used by multiple prompts
  • ✅ Shared team knowledge (architecture, standards, checklists)
  • ✅ Content needs separate maintenance from prompts
  • ✅ Changes should propagate to all prompts using it

When to embed content directly (single prompt use):

  • ✅ Content is specific to one prompt only
  • ✅ Content is not reused elsewhere
  • ✅ Prompt should be self-contained
  • ✅ No need for separate file management

Example: Embedded content (NOT using snippets):

---
name: security-review-api-only
description: Security review focused specifically on REST API endpoints
---

Review this API code for security issues using this checklist:

## API-Specific Security Checklist
- [ ] Input validation on all parameters
- [ ] SQL injection prevention (parameterized queries)
- [ ] Authentication on protected routes
- [ ] Rate limiting configured
- [ ] CORS properly configured
[... content embedded directly, not shared with other prompts ...]

Example: Using snippet file (reusable):

# In chat or prompt:
Review this code for security issues.

#file:.github/prompt-snippets/security-checklist.md

Templates

Templates come in two flavors with different purposes:

1. Generated Templates (Output Templates)

Definition: Structures that prompts generate as output (e.g., code scaffolds, documentation skeletons, configuration files).

Examples:

  • React component template (what a “generate component” prompt creates)
  • API endpoint structure (what a “create REST endpoint” prompt produces)
  • Test file layout (what a “scaffold tests” prompt outputs)

Storage: Reference these in prompt instructions, but don’t store as separate files unless needed for consistency.

Example in prompt file:

---
name: create-react-component
description: Generate a React component with TypeScript
---

Create a functional React component following this structure:

```tsx
import React from 'react';
import styles from './${componentName}.module.css';

interface ${componentName}Props {
  // Props here
}

export const ${componentName}: React.FC<${componentName}Props> = (props) => {
  return (
    <div className={styles.container}>
      {/* Component implementation */}
    </div>
  );
};
```

Include PropTypes and a basic test file.

2. Reusable Templates (Input Templates)

Definition: Starting points for creating new prompt files, agent files, or instruction files—templates you copy and fill in.

Examples:

  • Blank .prompt.md template with standard YAML fields
  • Agent definition template with common tools and handoffs
  • Instruction file template with applyTo pattern examples

Recommended location: .github/templates/ or .copilot/templates/

.github/
├── templates/
│   ├── prompt-template.md
│   ├── agent-template.md
│   ├── instruction-template.md
│   └── README.md  # Explains when to use each template

Example: .github/templates/prompt-template.md

---
name: [prompt-name]
description: [Brief description of what this prompt does]
agent: [ask|edit|agent]  # Optional: specify agent mode
model: [Model name]       # Optional: Claude Sonnet 4, GPT-4, etc.
tools: [tool1, tool2]     # Optional: limit available tools
argument-hint: [hint]     # Optional: help text for arguments
---

# [Prompt Title]

[Clear description of the task this prompt performs]

## Context

[Any background information Copilot needs]

## Instructions

1. [Step-by-step instructions]
2. [Be specific and actionable]

## Output Format

[Describe the expected output structure]

## Example

[Optional: provide an example of the desired result]

Decision Framework: Snippet vs. Template vs. Full Prompt

Asset Type Purpose Reusability Discoverability Typical Size
Prompt Snippet Context fragment for composition High (included in multiple prompts) Low (not indexed) < 50 lines
Generated Template Output structure definition Medium (referenced in prompts) Medium (via prompt docs) Varies
Input Template Starting point for new files Low (copy-once) Low (team documentation) ~50 lines
Full Prompt Standalone executable task High (team-wide command) High (slash/hashtag command) 50-500 lines

Organization Best Practices

1. Clear Separation

Don’t mix snippets, templates, and prompts in the same folder:

❌ BAD: Everything mixed together
.github/prompts/
├── create-component.prompt.md
├── security-checklist.md  # Is this a snippet or a prompt?
├── template.md            # What kind of template?

✅ GOOD: Clear folder structure
.github/
├── prompts/               # Executable prompt files
│   └── create-component.prompt.md
├── prompt-snippets/       # Reusable fragments
│   └── security-checklist.md
└── templates/             # Starting point files
    └── prompt-template.md

2. Document Usage

Include a README.md in each folder explaining:

  • What files are stored there
  • How to use them (copy, include, reference)
  • When to create new files vs. using existing ones

3. Version Control for Templates

When you update an input template, existing files created from that template are not automatically updated. Consider:

  • Documenting template versions in the template file itself
  • Creating migration guides when templates change significantly
  • Using prompts to standardize existing files when templates evolve

Example:

---
# Template Version: 2.1
# Last Updated: 2025-12-25
# Changelog: Added 'tools' and 'model' fields, removed deprecated 'mode' field
---

4. Snippet Composition Patterns

Pattern 1: Inline inclusion via #file (VS Code only)

Please analyze this code. #file:.github/prompt-snippets/security-checklist.md

Pattern 2: Manual copy-paste

Review the following for security issues:

[Content of security-checklist.md pasted here]

Pattern 3: Reference in prompt YAML Pattern 4: Markdown link (may work, less reliable)

Follow the guidelines in [security-checklist.md](.github/prompt-snippets/security-checklist.md).

Common Patterns

Snippets for Domain Context

.copilot/snippets/
├── business-rules.md      # Company-specific policies
├── architecture-overview.md  # System architecture summary
└── tech-stack.md          # Technology choices and versions

Use case: Include in multiple prompts requiring domain knowledge without duplicating content.

Templates for Consistency

.github/templates/
├── feature-prompt.md      # Template for feature implementation prompts
├── review-prompt.md       # Template for code review prompts
└── refactor-prompt.md     # Template for refactoring prompts

Use case: Ensure all team members create prompts with consistent structure.

Generated Templates in Prompts

---
name: scaffold-api-endpoint
---

Create a new API endpoint with this structure:

[Controller template code]
[Service template code]
[Test template code]

Replace placeholders with actual implementation.

Use case: Standardize generated code structures without requiring separate template files.

Key Takeaways

  • Snippets = Reusable context fragments included in other prompts
  • Generated Templates = Structures that prompts output (code scaffolds, docs)
  • Input Templates = Starting points for creating new prompt/agent/instruction files
  • Full Prompts = Standalone executable commands with YAML frontmatter

Store snippets and templates in dedicated folders, document their usage, and version them when they change. This organization ensures your team can easily find, reuse, and maintain supporting assets alongside core prompt files.


⚠️ Common Mistakes

Even with clear guidance on file organization, teams frequently make mistakes that reduce discoverability, create maintenance burdens, or cause confusion. Here are the most common organizational pitfalls and how to avoid them.

Mistake 1: Mixing File Types in the Same Folder

Problem: Storing prompts, snippets, templates, and documentation in the same folder makes it unclear which files are executable commands versus reference materials.

❌ Bad example:

.github/prompts/
├── create-component.prompt.md     # Executable prompt
├── security-checklist.md          # Is this a prompt or a snippet?
├── template.md                    # What kind of template?
├── architecture-notes.md          # Documentation?
└── README.md

✅ Solution: Separate by type with clear folder structure:

.github/
├── prompts/                       # Only executable .prompt.md files
│   └── create-component.prompt.md
├── prompt-snippets/               # Reusable fragments
│   └── security-checklist.md
├── templates/                     # Starting point files
│   └── prompt-template.md
└── docs/                          # Team documentation
    └── architecture-notes.md

Mistake 2: Inconsistent Naming Conventions

Problem: Team members use different naming styles, making prompts hard to discover and remember.

❌ Bad examples:

.github/prompts/
├── CreateReactComponent.prompt.md        # PascalCase
├── generate_unit_tests.prompt.md         # snake_case
├── ReviewAPI.prompt.md                   # Abbreviated, unclear
└── refactor-code-for-performance.prompt.md  # Too verbose

✅ Solution: Establish team convention (kebab-case recommended):

.github/prompts/
├── create-react-component.prompt.md      # Clear, concise, kebab-case
├── generate-unit-tests.prompt.md         # Consistent pattern
├── review-api-security.prompt.md         # Full words, not abbreviated
└── refactor-performance.prompt.md        # Descriptive but concise

Naming guidelines:

  • Use kebab-case (lowercase with hyphens)
  • Start with action verb (create, generate, review, refactor)
  • Include domain/technology when relevant (react, api, database)
  • Keep under 5 words for command brevity

Mistake 3: Wrong Extension or Location

Problem: Using incorrect file extensions or storing files in unrecognized locations prevents Copilot from discovering them.

❌ Bad examples:

.github/
├── copilot/prompts/                   # Wrong: Copilot doesn't scan here
│   └── my-prompt.prompt.md
├── prompts/
│   ├── another-prompt.prompt          # Wrong: Missing .md extension
│   └── yet-another.md                 # Wrong: Missing .prompt part
└── my-instructions.md                 # Wrong: Should be copilot-instructions.md

✅ Solution: Use official paths and extensions:

.github/
├── prompts/                           # Correct location
│   └── my-prompt.prompt.md            # Correct: .prompt.md extension
├── copilot-instructions.md            # Correct: exact filename
└── instructions/
    └── python-rules.instructions.md   # Correct: .instructions.md extension

Critical rules:

  • Prompt files: .github/prompts/*.prompt.md (not .prompt alone)
  • Repository instructions: .github/copilot-instructions.md (exact name)
  • Path-specific instructions: .github/instructions/*.instructions.md
  • Agents (VS Code): .github/agents/*.agent.md

Mistake 4: No README or Documentation

Problem: New team members don’t know which prompts exist, what they do, or when to use them.

❌ Bad example:

.github/prompts/
├── p1.prompt.md
├── p2.prompt.md
├── p3.prompt.md
└── p4.prompt.md

No explanation of purpose, no usage examples, no maintenance notes.

✅ Solution: Add README.md in each folder:

<!-- .github/prompts/README.md -->
# Team Prompts

## Available Prompts

| Command | Purpose | When to Use |
|---------|---------|-------------|
| `/create-react-component` | Generate functional React component | Creating new UI components |
| `/generate-unit-tests` | Create Jest tests for selected code | After writing new functions |
| `/review-api-security` | Security audit for API endpoints | Before deploying API changes |

## Usage

1. Open Copilot Chat
2. Type `/` to see available prompts
3. Select prompt or type `/promptName`
4. Provide required context (selection, arguments)

## Adding New Prompts

See `.github/templates/prompt-template.md` for the standard structure.

Mistake 5: Orphaned or Outdated Files

Problem: Old prompts remain in the repository long after they’re obsolete, creating confusion and clutter.

❌ Bad example:

.github/prompts/
├── create-class-component.prompt.md       # Obsolete: Team uses hooks now
├── use-moment-js.prompt.md                # Obsolete: Migrated to date-fns
├── generate-flow-types.prompt.md          # Obsolete: Migrated to TypeScript
└── review-webpack-config.prompt.md        # Obsolete: Using Vite now

✅ Solution: Regular maintenance with deprecation markers:

---
# create-class-component.prompt.md
name: create-class-component
description: "⚠️ DEPRECATED: Use /create-react-component instead (functional components)"
---

**This prompt is deprecated.**

Our team migrated to functional components with hooks.
Use `/create-react-component` instead.

This file will be removed on 2025-03-01.

Maintenance checklist:

Mistake 6: User Prompts for Team-Wide Tasks

Problem: Creating prompts in user-scope folder when they should be shared with the entire team.

❌ Bad example:

# Developer creates prompt in:
%APPDATA%\Code\User\prompts\review-api-security.prompt.md

# Problem: Only available on that developer's machine
# Team can't use it, can't improve it, can't maintain it

✅ Solution: Workspace prompts for team tasks, user prompts for personal workflows:

# Team-shared prompts (version controlled):
.github/prompts/
├── review-api-security.prompt.md      # Everyone needs this
├── generate-unit-tests.prompt.md      # Team standard

# Personal prompts (developer's profile folder):
%APPDATA%\Code\User\prompts/
├── my-notes-format.prompt.md          # Personal note-taking style
└── my-commit-message.prompt.md        # Personal commit preferences

Decision framework:

  • Workspace prompts (.github/prompts/) → Team standards, project-specific tasks, shared workflows
  • User prompts (profile folder) → Personal preferences, individual workflows, cross-project utilities

Mistake 7: No Versioning Strategy for Templates

Problem: Teams update templates but don’t version them, breaking consistency for files created from older versions.

❌ Bad example:

---
# .github/templates/prompt-template.md
name: [prompt-name]
description: [description]
---
# [Prompt Title]

[Instructions...]

No version number, no changelog, no way to know if existing prompts follow current template.

✅ Solution: Version templates and document changes:

---
# Template Version: 2.1.0
# Last Updated: 2025-12-25
# Changelog:
#   v2.1.0 (2025-12-25): Added 'tools' field for tool restrictions
#   v2.0.0 (2025-11-01): Added 'model' field, removed deprecated 'mode'
#   v1.0.0 (2025-09-15): Initial template
#
# Instructions:
# 1. Copy this file to .github/prompts/
# 2. Rename to [your-prompt-name].prompt.md
# 3. Fill in all [bracketed] fields
# 4. Remove this header comment before committing
---
name: [prompt-name]
description: [Brief description of what this prompt does]
tools: [fetch, search, ...]  # v2.1.0: Optional tool restrictions
model: [Model name]           # v2.0.0: Optional model selection
---

# [Prompt Title]

[Clear description of the task]

## Instructions

1. [Step-by-step instructions]

Key Takeaways

DO:

  • Separate file types into dedicated folders
  • Use consistent naming conventions (kebab-case recommended)
  • Follow official file locations and extensions
  • Document prompts with README files
  • Regularly review and deprecate outdated prompts
  • Use workspace prompts for team tasks, user prompts for personal workflows
  • Version templates and track changes

DON’T:

  • Mix prompts, snippets, templates, and docs in one folder
  • Use inconsistent naming styles across team
  • Store files in unrecognized locations or use wrong extensions
  • Leave prompts undocumented
  • Keep obsolete prompts indefinitely
  • Put team-wide prompts in personal user folder
  • Update templates without versioning

By avoiding these common mistakes, you’ll create a well-organized, discoverable, and maintainable prompt library that serves your entire team effectively.


📚 References

Official GitHub Copilot Documentation

  • GitHub Copilot Custom Instructions [📘 Official]
    This reference explains how to create repository-level custom instructions using .github/copilot-instructions.md to guide Copilot’s behavior across your project. It covers the syntax, best practices, and how these instructions are automatically applied to all chat requests when enabled. Essential for understanding how to standardize Copilot’s responses to match your team’s coding standards and conventions.

  • Using Prompt Files [📘 Official]
    Learn how to create reusable prompt files in .github/prompts/ that become slash commands in VS Code or hashtag commands in Visual Studio. This guide covers the .prompt.md file format, YAML frontmatter options (including tools, agent, model, and variable references like ${selection}), and how to structure prompts for maximum reusability. Critical for teams wanting to create shared, discoverable prompts.

  • Path-Specific Instructions [📘 Official]
    Documentation on using .github/instructions/ folder with .instructions.md files that apply to specific file patterns using glob syntax. This allows you to create granular rules that only apply to certain directories or file types, making your Copilot guidance more contextual and precise. Includes the new excludeAgent frontmatter option to control which agents use the instructions.

VS Code Copilot Features

  • VS Code Copilot Chat Documentation [📘 Official]
    Comprehensive guide to using Copilot Chat in VS Code, including chat participants, slash commands, and context variables like #file and #fetch. Essential for understanding how to reference files and external resources within your prompts and how to leverage VS Code’s chat interface effectively.

  • Custom Agents in VS Code [📘 Official]
    Documentation for creating custom agents using .agent.md files in .github/agents/. Explains how to define specialized AI personas with specific tools, behaviors, handoff capabilities for workflow transitions, and model selection. Custom agents (formerly “chat modes”) became stable in VS Code 1.106. Important for teams building advanced workflow automation with multiple specialized agents.

VS Code Release Notes

  • VS Code v1.107 Release Notes [📘 Official]
    December 2024 release introducing Agent HQ unified interface, background agents with work tree isolation, MCP 1.0 features, GitHub MCP Server (Preview), enhanced Language Models Editor with BYOK support, and Claude skills integration. Essential for understanding the latest agentic development capabilities and agent execution contexts.

Visual Studio Copilot Features

  • GitHub Copilot in Visual Studio [📘 Official]
    Microsoft’s official documentation for using GitHub Copilot in Visual Studio 2022 (version 17.10+). Covers hashtag commands, prompt files support, and custom instructions. Essential for teams using Visual Studio to understand platform-specific features and compatibility.

  • Prompt Files in Visual Studio [📘 Official]
    Details on how Visual Studio implements prompt files with the hashtag command syntax and the differences from VS Code’s slash command approach. Important for cross-platform teams to understand how prompt files work consistently across different IDEs.

Community Best Practices

  • Awesome GitHub Copilot - Prompt Engineering [📒 Community]
    Community-curated collection of resources, tips, and examples for working with GitHub Copilot. Includes practical prompt engineering techniques, repository organization patterns, and real-world examples from various teams. Valuable for discovering innovative approaches to prompt organization and learning from community experiences.

  • The .copilot Context Pattern [📒 Community]
    GitHub code search results showing real-world implementations of the .copilot/context/ pattern. Explore how different teams organize domain knowledge, schemas, and reference materials to enhance Copilot’s contextual awareness. Useful for seeing practical examples of context organization strategies.

Semantic Search and Context

  • How GitHub Copilot Uses Context [📘 Official]
    Explains how Copilot’s semantic search indexes your repository to find relevant context. Understanding this mechanism helps you organize documentation and reference materials in ways that maximize Copilot’s ability to find and use them effectively.

  • Workspace Context Best Practices [📘 Official]
    VS Code documentation on how to structure your workspace to provide optimal context to Copilot. Covers file organization, documentation placement, workspace indexing (local and remote via GitHub/Azure DevOps), and the difference between @workspace and #codebase (the latter is now recommended for flexibility).


These references provide comprehensive coverage of GitHub Copilot’s file organization features, from official documentation to community best practices, ensuring you have authoritative sources for all recommendations in this article.


📎 Appendix A: Legacy .chatmode.md Migration

Deprecated as of: VS Code 1.106
Replaced by: .agent.md files in .github/agents/

Prior to VS Code 1.106, custom agents were called “chat modes” and used different file conventions:

Legacy Current
.chatmode.md extension .agent.md extension
.github/chatmodes/ folder .github/agents/ folder
Limited frontmatter fields Extended frontmatter with handoffs, target, mcp-servers

Migration Steps

  1. VS Code automatically recognizes legacy .chatmode.md files as custom agents
  2. Open any .chatmode.md file and use the Quick Fix action (lightbulb) to migrate
  3. The Quick Fix renames the file to .agent.md and moves it to .github/agents/
  4. Update any team documentation referencing the old paths

New Frontmatter Fields

Custom agents now support additional configuration options:

---
description: Generate an implementation plan
name: Planner
tools: ['fetch', 'githubRepo', 'search']
model: Claude Sonnet 4
target: vscode  # or 'github-copilot' for remote agents
handoffs:
  - label: Start Implementation
    agent: agent
    prompt: Implement the plan outlined above.
    send: false
mcp-servers:  # For github-copilot target only
  - name: my-server
    url: https://...
---

For detailed guidance on creating and structuring custom agent files, including persona design, tool configuration, and handoff workflows, see How to Structure Content for Copilot Agent Files.